Typical data processor bus system configurations are too slow and cumbersome when used for System on a Chip (SoC) type architecture communications, especially when multiple data streams are simultaneously required. Conventional parallel buses would provide the data transfer capability, but they are prone to skew errors, while conventional serial buses require clocking, either hardwired or regenerated. Another possibility is to use multilevel signaling. Multilevel buses can be used in such a way that the transmitted amplitude is changed, even if the same symbol is sent at consecutive bit periods, in order to provide an inherent clocking signal. This signaling method is, however, presently used more to provide scalable asynchronous bit rates from zero to very high values, rather than to increase the information content. As may be appreciated, the applicability of a serial multilevel bus, and other bus types, is enhanced if fast, low latency signaling could be used without hardwired control signals, or the use of short packets.
A communication link is conventionally depicted as a layered model, as exemplified by FIG. 1, which shows how the information is packaged at the different protocol layers between a sending process 101 and a receiving process 102. Header information is added at each higher level. For example, an Application Header (AH) is added at the Application layer, a Presentation Header (PH) is added at the Presentation layer, and so on. While actual transmission takes place only at the physical layer 100, each receiver layer is conceptually in contact with the matching transmitting layer, and can conceptually signal at the same level using a reverse channel.
In reality, each layer only communicates with the layer above or below it, and adds respective header 103, 104 information during the process. What can be observed is that the use of any higher layer for flow control increases the response time, because of the additional header(s) 103. Note that usually a data termination header 106 is inserted at the datalink level, but this can be omitted by including the size of the frame in the header 104 itself, or specifying that the next header is considered to be the data termination.
Regardless of the electrical interface method, serial or parallel, asynchronous or synchronous, with a separate clock line or with a regenerated clock signal, a system constraint when using the same layer for flow control signaling is the latency time. In conventional serial links the latency time is to a great extent directly related to the information packet frame length on the lowest protocol levels. A short frame length can provide the needed short latency time, because handshaking or interrupt signaling is not required to wait for a previous long frame to end. One solution would be to discard any long frame undergoing transmission in the middle of the frame, and to then send a new short frame containing the low latency signal. However, this approach is wasteful when the relative intensity of interrupt or handshaking signals is high. Using short frames on the lowest levels is not as wasteful as discarding frames, but this method is less desirable because of the framing header overhead, which is constant regardless of the requirement to send low latency signals.
Mobile media terminals contain modules connected by standardized high bandwidth point-to-point serial or parallel links. Many of these links must simultaneously support both isochronous connections and asynchronous connections, high speed and low speed data transfer, and yet provide very fast latency time for control signals, even if the frame length varies for the different signals and streams, from very short to very long. The emergence of multimedia applications and the required high third generation (3G) performance all require very short and guaranteed latency times when integrating fast hardware (HW) processes to process voice, video and other multimedia streams. These and similar applications require a low latency time on a SoC. In addition, typical Graphical User Interface (GUI) driven multimedia applications generate various and changing data transfer and processing tasks that also need to be executed on the hardware platform.
While serial buses are the preferred choice for fast off-chip communication, parallel data buses are the preferred choice on-chip. However, parallel buses are prone to skewing errors when used for high speed data transfer. The use of a typical off-chip serial bus for off-chip communications is limited because of the requirement to provide a clocking signal. Clocking can be regenerated, which slows down the system, or alternatively asynchronous signaling can be employed. In this approach the clocking for the multilevel asynchronous bus is provided by the multilevel signal itself.
The failure by a single bus to provide sufficient data transfer speed represents a system bottleneck, thereby making the use of multiple point-to-point connections advantageous in a typical SoC architecture. These multiple point-to-point data streams are, however, complicated to control in a flexible way, and the dynamic control of data flow in a SoC architecture is a necessity when implementing flexible software driven applications.
A flexible yet fast method is clearly needed to handle control and interrupt signals with low latency time. The use of dedicated hardware connections would be optimal, but such connections are not always available over a bus connecting different chips or peripheral units.
Even if the frame length is short, such as in the case of the Inter-Integrated Circuit (I2C) bus (a simple two wire serial bus developed in the 1980s), a multinode system will impose latency-related system constraints when the signal is passed over multiple nodes. According to the I2C specification, a reverse acknowledgment must be received by the source at the next clock transition after the receipt of a character, and in a multi-node system this acknowledgment ripples through a chain of nodes. In this case the round-trip path total latency time can easily be too long for the handling of tunneling acknowledgments, thereby preventing the use of tunneling protocols.